Closes #403 .

Changes proposed in this pull request:

• The decision tree steps in selection are modularized in new functions and classes
• decision_tree_class.py contains the new class for initializing and running a decision tree
• selection/data/ contains json files that define a simpler, conservative decision tree and the full MEICA v2.7 decision tree
  -Most functions that define each decision tree step are in selection_nodes.py
  -There are some minor changes in decision tree steps that might result in breaking the existing tests

Known issues:

• Some functions in the MEICA decision tree haven't been run yet because they require linking to metric calculation functions. Those functions and all of PR [REF] Modularize metric calculation #447 is already merged into this code, to make that possible.
• The function documentation isn't being linked to and generated in the ReadTheDocs API section. The documentation also has some gaps. In particular, the documentation for the class structure is not done and there should be a guide explaining the json files for the decision trees and listing rules for creating a new decision tree (i.e. Even though it is possible, it is not advised to create a decision tree that can re-classify accepted or rejected components once they've received those labels)
• More checks and warnings can be added to various functions. For example, there can be a warning if an accepted or rejected component is reclassified at a later step
• There is repetitive code at the beginning of each decision tree function. That can be changed into an initialization function (or all the functions in selection_nodes.py could become a class, but that might be more hassle than it's worth). Either of these changes probably wouldn't make the code much shorter, but it would make it easier to know what is expected for each function
• Some of the functions for the later steps in the decision tree are ugly (i.e. highvariance_highmeanmetricrank_highkapparatio ). These are all functions that tweak metrics, threshold each of them separately, and use the intersection of those thresholded values to make a decision. I can theoretically make a multiple threshold comparison function that would be more generally useful. The minus is that would either break the current way decision nodes are set up, or push a lot more details and function calls into a decision node specification in the json file. On balance, I think these long functions with explanations of what they do are better than adding complexity to the json files, but this deserves a bit more thought. Also, I'm hoping we'll move away from decision trees with some messy joint measurements so I hope the currently messy functions will become legacy functions to maintain a rough replication of the MEICA method, but won't spawn too many additional messy functions.
• No testing functions have been written for this code yet
• All the other improvements that aren't coming to mind right now.